Hi @CrazySteve0605, I reviewed this PR against the Copilot comments from #19166. Most of the explicit comments are handled correctly, but I think two issues still need attention.

First, the braille offset-converter issue is still unresolved. braille.py still keeps only one converter. When Chinese word-segmentation spacing is applied first and Unicode normalization is also enabled, the segmentation converter is overwritten by the normalization converter. As a result, brailleToRawPos / rawToBraillePos are only mapped back through the last converter, so cursor routing / selection mapping can still be wrong. This probably needs converter composition, or applying the transformations while keeping a combined mapping back to the original raw text.

Second, _initCppJieba now calls cls._lib.initJieba(dictDir), but it does not check the returned boolean. Since the C++ side now returns false on initialization failure, the Python side should probably treat that as failure too, e.g. set cls._lib = None and log/debugWarn. Otherwise NVDA may think cppjieba is available even though it was not initialized successful.

The rest of the fixes look broadly in the right direction to me.

I will test the actual experience with Focus 80 later. The above is just a response to some points that Copilot raised that may need to be considered.

Hi @CrazySteve0605

While testing Chinese braille word segmentation, I found a regression: some NVDA built-in braille state abbreviations are being split by the word segmentation logic. For example, the checked state for a checkbox should remain ⣏⣿⣹, but with this feature enabled it becomes ⣏ ⣿ ⣹, with unexpected spaces inserted between the braille cells.

This seems to happen because WordSegWithSeparatorOffsetConverter is applied to the entire rawText in braille.Region.update(). That text contains not only user-facing content, but also NVDA-generated braille state abbreviations. The current segmentation logic avoids inserting spaces next to punctuation, but Braille Pattern characters are Unicode symbols, so they are not protected by that rule.

I think this should be fixed in this PR. A reasonable approach would be to avoid inserting word-segmentation separators between Braille Pattern characters, or more generally avoid inserting separators across symbol boundaries. It would also be good to add regression tests to ensure ⣏⣿⣹ remains unchanged, while normal Chinese text is still segmented as expected.

Btw, please remember to remove irrelevant .md file changes from the changes.

Thanks

Regarding Braille status abbreviations, please refer to this section in the user guide.

Thanks @CrazySteve0605

The fix works for me.
It's ready for review?

Hi @cary-rowen , thanks for reviews and testing.